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1. Introduction 


The Edwards-curve Digital Signature Algorithm (EdDSA) is a variant of 
Schnorr's signature system with (possibly twisted) Edwards curves. 
EdDSA needs to be instantiated with certain parameters, and this 
document describes some recommended variants. 


To facilitate adoption of EdDSA in the Internet community, this 
document describes the signature scheme in an implementation-oriented 
way and provides sample code and test vectors. 


The advantages with EdDSA are as follows: 


1. EdDSA provides high performance on a variety of platforms; 

2. The use of a unique random number for each signature is not 
required; 

3. It is more resilient to side-channel attacks; 


4. EdDSA uses small public keys (32 or 57 bytes) and signatures (64 
or 114 bytes) for Ed25519 and Ed448, respectively; 


5. The formulas are "complete", i.e., they are valid for all points 
on the curve, with no exceptions. This obviates the need for 
EdDSA to perform expensive point validation on untrusted public 
values; and 


6. EdDSA provides collision resilience, meaning that hash-function 
collisions do not break this system (only holds for PureEdDSA). 


The original EdDSA paper [EDDSA] and the generalized version 
described in "EdDSA for more curves" [EDDSA2] provide further 
background. RFC 7748 [RFC7748] discusses specific curves, including 
Curve25519 [CURVE25519] and Ed448-Goldilocks [ED448]. 


Ed25519 is intended to operate at around the 128-bit security level 
and Ed448 at around the 224-bit security level. A sufficiently large 
quantum computer would be able to break both. Reasonable projections 
of the abilities of classical computers conclude that Ed25519 is 
perfectly safe. Ed448 is provided for those applications with 
relaxed performance requirements and where there is a desire to hedge 
against analytical attacks on elliptic curves. 
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2. Notation and Conventions 


The following notation is used throughout the document: 


p Denotes the prime number defining the underlying field 
GF (p) Finite field with p elements 

x^y x multiplied by itself y times 

B Generator of the group or subgroup of interest 
[n]X X added to itself n times 

h[i] The i'th octet of octet string 

h i The i'th bit of h 

a || b (bit-)string a concatenated with (bit-)string b 
a <= b a is less than or equal to b 

a >= b a is greater than or equal to b 

itj Sum of i and j 

IA) Multiplication of i and j 

r=) Subtraction of j from i 

i/j Division of i by j 

ix j Cartesian product of i and j 

(u, v) Elliptic curve point with x-coordinate u and 


y-coordinate v 


SHAKE256(x, y) The y first octets of SHAKE256 [FIPS202] output for 


input x 
OCTET (x) The octet with value x 
OLEN (x) The number of octets in string x 
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dom2 (x, y) The blank octet string when signing or verifying 
Ed25519. Otherwise, the octet string: "SigEd25519 no 
Ed25519 collisions" || octet(x) || octet (OLEN (y)) || 
y, where x is in range 0-255 and y is an octet string 
of at most 255 octets.  "SigEd25519 no Ed25519 
collisions" is in ASCII (32 octets). 


dom4 (x, y) The octet string "SigEd448" || octet(x) || 
octet (OLEN (y) ) | | y, where x is in range 0-255 and y 
is an octet string of at most 255 octets.  "SigEd448" 


is in ASCII (8 octets). 


Parentheses (i.e., '(' and ’)’) are used to group expressions, in 
order to avoid having the description depend on a binding order 
between operators. 


Bit strings are converted to octet strings by taking bits from left 
to right, packing those from the least significant bit of each octet 
to the most significant bit, and moving to the next octet when each 
octet fills up. The conversion from octet string to bit string is 
the reverse of this process; for example, the 16-bit bit string 


b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 
is converted into two octets x0 and x1 (in this order) as 


x0 
x1 


b7*128+b6* 64+b5*32+b4*16+b3* 8+b2* 4+b1*2+b0 
b15*128+b14*64+b13*32+b12*16+b11*8+b10*4+b9*2+b8 


Little-endian encoding into bits places bits from left to right and 
from least significant to most significant. If combined with 
bit-string-to-octet-string conversion defined above, this results in 
little-endian encoding into octets (if length is not a multiple of 8, 
the most significant bits of the last octet remain unused). 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. EdDSA Algorithm 
EdDSA is a digital signature system with 11 parameters. 


The generic EdDSA digital signature system with its 11 input 
parameters is not intended to be implemented directly. Choosing 
parameters is critical for secure and efficient operation. Instead, 
you would implement a particular parameter choice for EdDSA (such as 
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Ed25519 or Ed448), sometimes slightly generalized to achieve code 
reuse to cover Ed25519 and Ed448. 


Therefore, a precise explanation of the generic EdDSA is thus not 
particularly useful for implementers. For background and 
completeness, a succinct description of the generic EdDSA algorithm 
is given here. 


The definition of some parameters, such as n and c, may help to 
explain some steps of the algorithm that are not intuitive. 


This description closely follows [EDDSA2]. 
EdDSA has 11 parameters: 


ale An odd prime power p. EdDSA uses an elliptic curve over the 
finite field GF(p). 


2; An integer b with 2^(b-1) > p. EdDSA public keys have exactly b 
bits, and EdDSA signatures have exactly 2*b bits. b is 
recommended to be a multiple of 8, so public key and signature 
lengths are an integral number of octets. 


35 A (b-1)-bit encoding of elements of the finite field GF(p). 


Ae A cryptographic hash function H producing 2*b-bit output. 
Conservative hash functions (i.e., hash functions where it is 
infeasible to create collisions) are recommended and do not have 
much impact on the total cost of EdDSA. 


Dis An integer c that is 2 or 3. Secret EdDSA scalars are multiples 
of 2ºc. The integer c is the base-2 logarithm of the so-called 
cofactor. 

6. An integer n with c <= n < b. Secret EdDSA scalars have exactly 


n + 1 bits, with the top bit (the 2^n position) always set and 
the bottom c bits always cleared. 


7. A non-square element d of GF(p). The usual recommendation is to 
take it as the value nearest to zero that gives an acceptable 
curve. 

8. A non-zero square element a of GF(p). The usual recommendation 
for best performance is a = -1 if p mod 4 = 1, and a = 1 if 


p mod 4 = 3. 


9. An element B != (0,1) of the set E = { (x,y) is a member of 
GF (p) x GF (p) such that a * x^2 + y^2 = 1 + d * x^2 * y^2 ). 
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10. An odd prime L such that [L]B = 0 and 2%c * L = fE. The number 
#E (the number of points on the curve) is part of the standard 
data provided for an elliptic curve E, or it can be computed as 
cofactor * order. 


11. A "prehash" function PH.  PureEdDSA means EdDSA where PH is the 


identity function, i.e., PH(M) = M. HashEdDSA means EdDSA where 
PH generates a short output, no matter how long the message is; 
for example, PH(M) = SHA-512(M). 

Points on the curve form a group under addition, (x3, y3) = (xl, yl) 


+ (x2, y2), with the formulas 
xl € y2 4X x2 * yd YL O do e as AKL x2 
1+d* xl * x2 * yl * y2 LS SD Ree A Y: ckoy2 
The neutral element in the group is (0,1). 


Unlike many other curves used for cryptographic applications, these 
formulas are "complete"; they are valid for all points on the curve, 
with no exceptions. In particular, the denominators are non-zero for 
all input points. 


There are more efficient formulas, which are still complete, that use 
homogeneous coordinates to avoid the expensive modulo p inversions. 
See [Faster-ECC] and [Edwards-revisited]. 


3.1. Encoding 


An integer 0 < S < L - 1 is encoded in little-endian form as a b-bit 
string ENC(S). 


An element (x,y) of E is encoded as a b-bit string called ENC(x,y), 
which is the (b-1)-bit encoding of y concatenated with one bit that 
is 1 if x is negative and 0 if x is not negative. 


The encoding of GF(p) is used to define "negative" elements of GF(p): 
specifically, x is negative if the (b-1)-bit encoding of x is 
lexicographically larger than the (b-1)-bit encoding of -x. 


3.2. Keys 


An ECDSA private key is a b-bit string k. Let the hash H(k) = 
(h_0, h 1, ..., h (2b-1)) determine an integer s, which is 2^n plus 
the sum of m = 2^i * h i for all integer i, c <= i < n. Let s 
determine the multiple A = [s]B. The EdDSA public key is ENC(A). 
The bits h b, ..., h (2b-1) are used below during signing. 
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3.3. “Sign 
The EdDSA signature of a message M under a private key k is defined 
as the PureEdDSA signature of PH(M). In other words, EdDSA simply 
uses PureEdDSA to sign PH(M). 


The PureEdDSA signature of a message M under a private key k is the 


2*b-bit string ENC(R) || ENC(S). R and S are derived as follows. 
First define r = H(h_b || ... || h_(2b-1) || M) interpreting 2*b-bit 
strings in little-endian form as integers in (0, 1, ..., 2% (2*b) - 
1}. Let R = [r]B and S = (r + H(ENC(R) || ENC(A) || PH(M)) * s) mod 


L. The s used here is from the previous section. 


3.4. Verify 


To verify a PureEdDSA signature ENC (R) | | ENC(S) on a message M under 
a public key ENC(A), proceed as follows. Parse the inputs so that A 
and R are elements of E, and S is a member of the set {0, 1, ..., 
L-1}. Compute h = H(ENC(R) || ENC(A) || M), and check the group 
equation [2%c * S] B = 2^c * R + [2%c * h] A in E. The signature is 
rejected if parsing fails (including S being out of range) or if the 
group equation does not hold. 


EdDSA verification for a message M is defined as PureEdDSA 
verification for PH(M). 


4. PureEdDSA, HashEdDSA, and Naming 


One of the parameters of the EdDSA algorithm is the "prehash" 
function. This may be the identity function, resulting in an 
algorithm called PureEdDSA, or a collision-resistant hash function 
such as SHA-512, resulting in an algorithm called HashEdDSA. 


Choosing which variant to use depends on which property is deemed to 
be more important between 1) collision resilience and 2) a single- 
pass interface for creating signatures. The collision resilience 
property means EdDSA is secure even if it is feasible to compute 
collisions for the hash function. The single-pass interface property 
means that only one pass over the input message is required to create 
a Signature. PureEdDSA requires two passes over the input. Many 
existing APIs, protocols, and environments assume digital signature 
algorithms only need one pass over the input and may have API or 
bandwidth concerns supporting anything else. 


Note that single-pass verification is not possible with most uses of 
signatures, no matter which signature algorithm is chosen. This is 
because most of the time, one can’t process the message until the 
signature is validated, which needs a pass on the entire message. 
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This document specifies parameters resulting in the HashEdDSA 
variants Ed25519ph and Ed448ph and the PureEdDSA variants Ed25519 and 
Ed448. 


5. EdDSA Instances 
This section instantiates the general EdDSA algorithm for the 
edwards25519 and edwards448 curves, each for the PureEdDSA and 
HashEdDSA variants (plus a contextualized extension of the Ed25519 
scheme). Thus, five different parameter sets are described. 


5.1. Ed25519ph, Ed25519ctx, and Ed25519 


Ed25519 is EdDSA instantiated with: 


4p----------- 4p------------------------------------------------------- t 
| Parameter | Value | 
4+----------- 4------------------------------------------------------- + 
| p | p of edwards25519 in [RFC7748] (i.e., 2^255 - 19) | 
| b | 256 | 
| encoding | 255-bit little-endian encoding of {0, 1, ..., p-1} | 

of GF (p) | 
| H (x) | SHA-512 (dom2 (phflag, context) | |x) [RFC6234] 
| € | base 2 logarithm of cofactor of edwards25519 in | 
| | [RFC7748] (i.e., 3) | 
| n | 254 | 
| d | d of edwards25519 in [RFC7748] (i.e., -121665/121666 | 
| | = 370957059346694393431380835087545651895421138798432 | 
| | 19016388785533085940283555) 

a -1 
| B | (X(P),Y(P)) of edwards25519 in [RFC7748] (i.e., (1511 | 
| | 22213495354007725011514095885315114540126930418572060 | 
| | 46113283949847762202, 4631683569492647816942839400347 | 
| 5163141307993866256225615783033603165251855960) ) 
L order of edwards25519 in [RFC7748] (i.e., 

| | 2^252+27742317777372353535851937790883648493). 
| PH(x) | x (i.e., the identity function) | 
+----------- +--------------------- - 5 = + 


Table 1: Parameters of Ed25519 
For Ed25519, dom2(f,c) is the empty string. The phflag value is 
irrelevant. The context (if present at all) MUST be empty. This 
causes the scheme to be one and the same with the Ed25519 scheme 
published earlier. 


For Ed25519ctx, phflag=0. The context input SHOULD NOT be empty. 
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For Ed25519ph, phflag=1 and PH is SHA512 instead. That is, the input 
is hashed using SHA-512 before signing with Ed25519. 


Value of context is set by the signer and verifier (maximum of 255 
octets; the default is empty string, except for Ed25519, which can't 
have context) and has to match octet by octet for verification to be 
successful. 


The curve used is equivalent to Curve25519 [CURVE25519], under a 
change of coordinates, which means that the difficulty of the 
discrete logarithm problem is the same as for Curve25519. 


5.1.1. Modular Arithmetic 


For advice on how to implement arithmetic modulo p = 2%255 - 19 
efficiently and securely, see Curve25519 [CURVE25519]. For inversion 
modulo p, it is recommended to use the identity x^-1 = x^(p-2) (mod 
p). Inverting zero should never happen, as it would require invalid 
input, which would have been detected before, or would be a 
calculation error. 


For point decoding or "decompression", square roots modulo p are 
needed. They can be computed using the Tonelli-Shanks algorithm or 
the special case for p = 5 (mod 8). To find a square root of a, 
first compute the candidate root x = a^((p*3)/8) (mod p). Then there 
are three cases: 


x^2 a (mod p). Then x is a square root. 


x^2 = -a (mod p). Then 2^((p-1)/4) * x is a square root. 
a is not a square modulo p. 
5.1.2. Encoding 


All values are coded as octet strings, and integers are coded using 
little-endian convention, i.e., a 32-octet string h h[0],...h[31] 
represents the integer h[0] + 2^8 * h[1] + ... + 2^248 * h[31]. 


A curve point (x,y), with coordinates in the range 0 <= x,y « p, is 
coded as follows. First, encode the y-coordinate as a little-endian 
string of 32 octets. The most significant bit of the final octet is 
always zero. To form the encoding of the point, copy the least 
significant bit of the x-coordinate to the most significant bit of 
the final octet. 
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5.1.3. Decoding 


Decoding a point, given as a 32-octet string, is a little more 


complicated. 

1. First, interpret the string as an integer in little-endian 
representation. Bit 255 of this number is the least significant 
bit of the x-coordinate and denote this value x_0. The 
y-coordinate is recovered simply by clearing this bit. If the 


resulting value is >= p, decoding fails. 


2. To recover the x-coordinate, the curve equation implies 
x^2 = (y?2 - 1) / (d y^2 + 1) (mod p). The denominator is always 
non-zero mod p. Let u = y^2 - 1 and v = d y^2 + 1. To compute 
the square root of (u/v), the first step is to compute the 
candidate root x = (u/v)”((p+3)/8). This can be done with the 
following trick, using a single modular powering for both the 
inversion of v and the square root: 


(p+3) /8 3 (p-5) /8 
x = (u/v) = u v (u v^T) (mod p) 


3. Again, there are three cases: 


1. If v x^2 


u (mod p), x is a square root. 


2. If v x^2 = -u (mod p), set x «-- x * 2^((p-1)/4), which is a 
square root. 


3. Otherwise, no square root exists for modulo p, and decoding 
fails. 


4. Finally, use the x O bit to select the right square root. If 
x = 0, and x O = 1, decoding fails. Otherwise, if x O != x mod 
2, set x <-- p - x. Return the decoded point (x,y). 
5.1.4. Point Addition 
For point addition, the following method is recommended. A point 
(x,y) is represented in extended homogeneous coordinates (X, Y, Z, 


T), with x = X/Z, y = Y/Z, x * y = T/Z. 


The neutral point is (0,1), or equivalently in extended homogeneous 
coordinates (0, Z, Z, 0) for any non-zero Z. 
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The following formulas for adding two points, (x3,y3) = 
(x1,y1)+(x2,y2), on twisted Edwards curves with a=-1, square a, and 
non-square d are described in Section 3.1 of [Edwards-revisited] and 
in [EFD-TWISTED-ADD]. They are complete, i.e., they work for any 
pair of valid input points. 


(Y1-X1)* (Y2-X2) 
= (Y1+X1) * (Y2*X2) 
= T1*2*d*T2 
= Z1*2*22 


KX m om"ubgmdug-lgaoogtu P 
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For point doubling, (x3,y3) = (x1,y1)+(x1,y1), one could just 
substitute equal points in the above (because of completeness, such 
substitution is valid) and observe that four multiplications turn 


into squares. However, using the formulas described in Section 3.2 
of [Edwards-revisited] and in [EFD-TWISTED-DBL] saves a few smaller 
operations. 


A = X1^2 

B = Y1º2 

C = 2*21^2 

H = A+B 

E = H-(X1+Y1)^2 
G 
F 


= A-B 
= CrG 
X3 = E*F 
Y3 = G*H 
T3 = E*H 
Z3 = F*G 
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5. Key Generation 


The private key is 32 octets (256 bits, corresponding to b) of 
cryptographically secure random data. See [RFC4086] for a discussion 
about randomness. 


The 32-byte public key is generated by the following steps. 
1. Hash the 32-byte private key using SHA-512, storing the digest in 


a 64-octet large buffer, denoted h. Only the lower 32 bytes are 
used for generating the public key. 


2. Prune the buffer: The lowest three bits of the first octet are 
cleared, the highest bit of the last octet is cleared, and the 
second highest bit of the last octet is set. 


3. Interpret the buffer as the little-endian integer, forming a 
secret scalar s. Perform a fixed-base scalar multiplication 
[s]B. 


4. The public key A is the encoding of the point [s]B. First, 
encode the y-coordinate (in the range 0 <= y « p) as a little- 


endian string of 32 octets. The most significant bit of the 
final octet is always zero. To form the encoding of the point 
[s]B, copy the least significant bit of the x coordinate to the 
most significant bit of the final octet. The result is the 
public key. 

6. Sign 


The inputs to the signing procedure is the private key, a 32-octet 
string, and a message M of arbitrary size. For Ed25519ctx and 
Ed25519ph, there is additionally a context C of at most 255 octets 
and a flag F, 0 for Ed25519ctx and 1 for Ed25519ph. 


1. Hash the private key, 32 octets, using SHA-512. Let h denote the 
resulting digest. Construct the secret scalar s from the first 
half of the digest, and the corresponding public key A, as 
described in the previous section. Let prefix denote the second 
half of the hash digest, h[32],...,h[63]. 


2. Compute SHA-512(dom2(F, C) || prefix || PH(M)), where M is the 
message to be signed. Interpret the 64-octet digest as a little- 
endian integer r. 


3. Compute the point [r]B. For efficiency, do this by first 
reducing r modulo L, the group order of B. Let the string R be 
the encoding of this point. 
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Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 
64-octet digest as a little-endian integer k. 


Compute S = (r + k * s) mod L. For efficiency, again reduce k 
modulo L first. 


Form the signature of the concatenation of R (32 octets) and the 
little-endian encoding of S (32 octets; the three most 
significant bits of the final octet are always zero). 


Verify 


To verify a signature on a message M using public key A, with F 
being 0 for Ed25519ctx, 1 for Ed25519ph, and if Ed25519ctx or 
Ed25519ph is being used, C being the context, first split the 
signature into two 32-octet halves.  Decode the first half as a 
point R, and the second half as an integer S, in the range 

0 <= s < L. Decode the public key A as point A’. If any of the 
decodings fail (including S being out of range), the signature is 
invalid. 


Compute SHA512(dom2(F, C) || R || A || PH(M)), and interpret the 
64-octet digest as a little-endian integer k. 


Check the group equation [8][S]B = [8]R + [8][k]A’. It’s 
sufficient, but not required, to instead check [S]B = R + [k]A’. 
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5.2. Ed448ph and Ed448 


Ed448 is EdDSA instantiated with: 


+----------- AS SS eS Ss SS + 
| Parameter | Value | 
do 4------------------------------------------------------- t 
| p | p of edwards448 in [RFC7748] (i.e., 2^448 - 2^224 - | 
1) 
| ibe. (ase | 
| encoding | 455-bit little-endian encoding of {0, 1, ..., p-1} | 
| of GF(p) | | 
| H (x) | SHAKE256 (dom4 (phflag, context) | |x, 114) | 
| phflag | 0 | 
| c | base 2 logarithm of cofactor of edwards448 in 
| [RFC7748] (i.e., 2) | 
| n 447 
| d | d of edwards448 in [RFC7748] (i.e., -39081) | 
a E 
| B | (X(P),Y(P)) of edwards448 in [RFC7748] (i.e., (224580 | 
| | 04029592430018760433409989603624678964163256413424612 | 
54616869504154674060329090291928693579532825780320751 
| | 46446173674602635247710, 2988192100784814926760179304 | 
| | 43930673437544040154080242095928241372331506189835876 | 
| | 00353687865541878473398230323350346250053154506283266 | 
0)) 
| L | order of edwards448 in [RFC7748] (i.e., 27446 - 13818 | 
| | 06680989511535200738674851542688033669247488217860989 | 
4547503885). 
| PH(x) | x (i.e., the identity function) | 
do O SS = SS SS = + 


Table 2: Parameters of Ed448 


Ed448ph is the same but with PH being SHAKE256(x, 64) and phflag 
being 1, i.e., the input is hashed before signing with Ed448 with a 
hash constant modified. 


Value of context is set by signer and verifier (maximum of 255 
octets; the default is empty string) and has to match octet by octet 


for verification to be successful. 


The curve is equivalent to Ed448-Goldilocks under change of the 
basepoint, which preserves difficulty of the discrete logarithm. 
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5.2.1. Modular Arithmetic 


For advice on how to implement arithmetic modulo p = 2^448 - 2%224 - 
1 efficiently and securely, see [ED448]. For inversion modulo p, it 
is recommended to use the identity x^-1 = x^(p-2) (mod p). Inverting 


zero should never happen, as it would require invalid input, which 
would have been detected before, or would be a calculation error. 


For point decoding or "decompression", square roots modulo p are 
needed. They can be computed by first computing candidate root 

x =a ^ (p+1)/4 (mod p) and then checking if x*2 = a. If it is, then 
x is the square root of a; if it isn't, then a does not have a square 
root. 


5.2.2. Encoding 


All values are coded as octet strings, and integers are coded using 
little-endian convention, i.e., a 57-octet string h h[0],...h[56] 
represents the integer h[0] + 2^8 * h[1] +... + 2^448 * h[56]. 


A curve point (x,y), with coordinates in the range 0 <= x,y « p, is 
coded as follows. First, encode the y-coordinate as a little-endian 
string of 57 octets. The final octet is always zero. To form the 
encoding of the point, copy the least significant bit of the 
x-coordinate to the most significant bit of the final octet. 


5.2.3. Decoding 


Decoding a point, given as a 57-octet string, is a little more 


complicated. 

1. First, interpret the string as an integer in little-endian 
representation. Bit 455 of this number is the least significant 
bit of the x-coordinate, and denote this value x_0. The 
y-coordinate is recovered simply by clearing this bit. If the 


resulting value is >= p, decoding fails. 


2. To recover the x-coordinate, the curve equation implies 
x^2 = (y?2 - 1) / (d y^2- 1) (mod p). The denominator is always 
non-zero mod p. Let u = y*2 - 1 and v = d y^2- 1. To compute 
the square root of (u/v), the first step is to compute the 
candidate root x = (u/v)^((p*1)/4). This can be done using the 
following trick, to use a single modular powering for both the 
inversion of v and the square root: 


(p+1)/4 3 (p-3) /4 
x = (u/v) = u v (u^5 v^3) (mod p) 
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3. If v * x^2 = u, the recovered x-coordinate is x. Otherwise, no 
square root exists, and the decoding fails. 


4. Finally, use the x_0 bit to select the right square root. If 
x = 0, and x O = 1, decoding fails. Otherwise, if x_0 != x mod 
2, set x <-- p - x. Return the decoded point (x,y). 


5.2.4. Point Addition 


For point addition, the following method is recommended. A point 
(x,y) is represented in projective coordinates (X, Y, Z), with 
x = X2; y = XA. 


The neutral point is (0,1), or equivalently in projective coordinates 
(0, Z, Z) for any non-zero Z. 


The following formulas for adding two points, (x3,y3) = 
(x1,y1)+(x2,y2) on untwisted Edwards curve (i.e., a=1) with non- 
square d, are described in Section 4 of [Faster-ECC] and in 
[EFD-ADD]. They are complete, i.e., they work for any pair of valid 
input points. 


= Z1*22 

= A^2 

= X1*X2 

= Y1*Y2 

= d*C*D 

B-E 

= BtE 
(X1+Y1) * (X2+Y2) 
A*F* (H-C-D) 
A*G* (D-C) 

= F*G 


Ho» m qQh'rpmuotu P 
WW 


N 
w 
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Again, similar to the other curve, doubling formulas can be obtained 
by substituting equal points, turning four multiplications into 
squares. However, this is not even nearly optimal; the following 
formulas described in Section 4 of [Faster-ECC] and in [EFD-DBL] save 
multiple multiplications. 


B (X1*Y1)^2 
C = X1^2 

D = Y1?%2 
E 
H 


C+D 

Z1%2 

J = E-2*H 
(B-E) *J 
E* (C-D) 
Z3 = E*J 


KX 
w w 
Io 


5.2.5. Key Generation 


The private key is 57 octets (456 bits, corresponding to b) of 
cryptographically secure random data. See [RFC4086] for a discussion 
about randomness. 


The 57-byte public key is generated by the following steps: 
1. Hash the 57-byte private key using SHAKE256(x, 114), storing the 


digest in a 114-octet large buffer, denoted h. Only the lower 57 
bytes are used for generating the public key. 


2. Prune the buffer: The two least significant bits of the first 
octet are cleared, all eight bits the last octet are cleared, and 
the highest bit of the second to last octet is set. 


3. Interpret the buffer as the little-endian integer, forming a 
secret scalar s. Perform a known-base-point scalar 
multiplication [s]B. 


4. The public key A is the encoding of the point [s]B. First encode 
the y-coordinate (in the range 0 <= y < p) as a little-endian 
string of 57 octets. The most significant bit of the final octet 
is always zero. To form the encoding of the point [s]B, copy the 
least significant bit of the x coordinate to the most significant 
bit of the final octet. The result is the public key. 
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5.2.6. Sign 


The inputs to the signing procedure is the private key, a 57-octet 
string, a flag F, which is 0 for Ed448, 1 for Ed448ph, context C of 
at most 255 octets, and a message M of arbitrary size. 


1. Hash the private key, 57 octets, using SHAKE256(x, 114). Let h 
denote the resulting digest. Construct the secret scalar s from 
the first half of the digest, and the corresponding public key A, 
as described in the previous section. Let prefix denote the 
second half of the hash digest, h[57],...,h[113]. 


2. Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114), where M is 
the message to be signed, F is 1 for Ed448ph, 0 for Ed448, and C 
is the context to use. Interpret the 114-octet digest as a 


little-endian integer r. 


3. Compute the point [r]B. For efficiency, do this by first 
reducing r modulo L, the group order of B. Let the string R be 
the encoding of this point. 


4. Compute SHAKE256(dom4(F, C) || R || A |] PH(M), 114), and 
interpret the 114-octet digest as a little-endian integer k. 


5. Compute S = (r + k * s) mod L. For efficiency, again reduce k 
modulo L first. 


6. Form the signature of the concatenation of R (57 octets) and the 
little-endian encoding of S (57 octets; the ten most significant 
bits of the final octets are always zero). 


5.2.7. Verify 


1. To verify a signature on a message M using context C and public 
key A, with F being 0 for Ed448 and 1 for Ed448ph, first split 
the signature into two 57-octet halves.  Decode the first half as 
a point R, and the second half as an integer S, in the range 0 <= 
S < L. Decode the public key A as point A’. If any of the 
decodings fail (including S being out of range), the signature is 
invalid. 


2. Compute SHAKE256(dom4(F, C) || R || A || PH(M), 114), and 
interpret the 114-octet digest as a little-endian integer k. 


3. Check the group equation [4][S]B = [4]R + [4][k]A’. It’s 
sufficient, but not required, to instead check [S]B = R + [k]A’. 
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6. Ed25519 Python Illustration 


The rest of this section describes how Ed25519 can be implemented in 
Python (version 3.2 or later) for illustration. See Appendix A for 
the complete implementation and Appendix B for a test-driver to run 
it through some test vectors. 


Note that this code is not intended for production as it is not 
proven to be correct for all inputs, nor does it protect against 
side-channel attacks. The purpose is to illustrate the algorithm to 
help implementers with their own implementation. 

## First, some preliminaries that will be needed. 


import hashlib 


def sha512(s): 
return hashlib.sha512(s) .digest () 


# Base field Z_p 
p = 2**255 - 19 


def modp inv (x): 
return pow(x, p-2, p) 


# Curve constant 
d = -121665 * modp_inv(121666) $ p 


X 


# Group order 
q = 2**252 + 27742317777372353535851937790883648493 


def sha512_modq(s): 
return int.from_bytes(sha512(s), "little") $ q 


## Then follows functions to perform point operations. 


# Points are represented as tuples (X, Y, Z, T) of extended 
# coordinates, with x = X/Z, y = Y/Z, x*y = T/Z 


def point_add(P, Q): 
A, B = (P[1]-P[0]) * (Q[1]-Q[0]) $ p, (P[1]+P[0]) * (Q[1]+Q[0]) $ p; 
C, D=2 * P[3] *0[3] * d$ p, 2 * P[2] * Q[2] $ p; 
E, F, G, H = B-A, D-C, D+C, BH; 
return (E*F, G*H, F*G, E*H); 
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# Computes Q = s * Q 
def point_mul(s, P): 
Q = (0, 1, 1, 0) # Neutral element 
while s > 0: 
if s & 1: 
Q = point add(Q, P) 
P = point add(P, P) 
s >>= 1 
return Q 
def point_equal (P, Q): 
d xl / zl == x2 / z2 <==> xl * z2 == x2 * z1 
if (P[0] * Q[2] = QIO] * P[2]) $ p != 0: 
return False 
if (PIII ESQUI —QLbp SP 2). ep. PO 
return False 
return True 
## Now follows functions for point compression. 


# Square root of -1 


modp sqrt m1 = pow(2, (p-1) // 4, 


# Compute corresponding x-coordinate, 


# sign, or return None on failure 
def recover_x(y, sign): 
if y >=p: 
return None 
x2 = 
if x2 
if sign: 
return None 
else: 
return 0 


# Compute square root of x2 


x = pow(x2, (p+3) // 8, p) 
if (x*x — x2) $ p != 0: 
X = x * modp sqrt ml $ p 
if (x*x — x2) $ p != 0: 
return None 
if (x & 1) != sign: 
x =p-x 


return x 
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# Base point 


GY 


def 


= 4 * modp inv(5) % p 
recover x(g y, 0) 
(gx gy, 1, g_x * g y $ p) 


point compress (P) 

zinv = modp inv(P[2 
x = P[0] * zinv $ p 
y = P[1] * zinv $ p 
return int.to_bytes (y | ((x & 1) << 255), 32, "little") 


1) 


point decompress (s): 
if len(s) != 32: 
raise Exception("Invalid input length for decompression") 
y = int.from bytes(s, "little") 
sign = y >> 255 
y £= (1 << 255) - 1 


x = recover_x(y, sign) 
if x is None: 
return None 
else: 
return (x, y, 1, x*y % p) 


## These are functions for manipulating the private key. 


def 


def 
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secret_expand (secret): 
if len(secret) != 32: 
raise Exception("Bad size of private key") 
= sha512 (secret) 
= int.from_bytes(h[:32], "little") 
&= (1 << 254) - 8 
|= (1 << 254) 
return (a, h[32:]) 


secret_to_public(secret): 
(a, dummy) = secret_expand(secret) 
return point_compress (point_mul (a, G)) 
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## The signature function works as below. 


def sign(secret, msg): 
a, prefix = secret_expand(secret) 
A = point_compress (point_mul(a, G)) 
r = sha512_modq (prefix + msg) 
R = point_mul(r, G) 
Rs = point compress (R) 
h = sha512_modq(Rs + A + msg) 
s= (r * h* a) $q 
return Rs + int.to bytes(s, 32, "little") 


## And finally the verification function. 


def verify(public, msg, signature): 


if len(public) != 32: 
raise Exception("Bad public key length") 
if len(signature) !- 64: 


Exception("Bad signature length") 
A = point decompress (public) 


if not A: 
return False 
Rs — signature[:32] 
R = point decompress (Rs) 
if not R: 
return False 
S — int.from bytes(signature[32:], "little") 


if s >= q: return False 

h = sha512 modq(Rs + public + msg) 

sB = point_mul(s, G) 

hA = point_mul(h, A) 

return point_equal(sB, point_add(R, hA)) 


7. Test Vectors 


This section contains test vectors for Ed25519ph, Ed25519ctx, 
Ed448ph, Ed25519, and Ed448. 


Each section contains a sequence of test vectors. The octets are hex 
encoded, and whitespace is inserted for readability. Ed25519, 
Ed25519ctx, and Ed25519ph private and public keys are 32 octets; 
signatures are 64 octets. Ed448 and Ed448ph private and public keys 
are 57 octets; signatures are 114 octets. Messages are of arbitrary 
length. If the context is non-empty, it is given as 1-255 octets. 
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7.1. Test Vectors for Ed25519 


These test vectors are taken from [ED25519-TEST-VECTORS] (but we 
removed the public key as a suffix of the private key and removed the 
message from the signature) and [ED25519-LIBGCRYPT-TEST-VECTORS]. 


ALGORITHM: 
Ed25519 


SECRET KEY: 
9d61b19deffd5a60ba844af492ec2cc4 
4449c5697b326919703bac031cae7f60 


PUBLIC KEY: 
d75a980182b10ab7d54bfed3c964073a 
0ee172f3daa62325af021a68f707511a 


MESSAGE (length 0 bytes): 


SIGNATURE: 

e5564300c360ac729086e2cc806e828a 
84877£1eb8e5d974d873e06522490155 
5fb8821590a33bacc6le39701cf9b46b 
d25bf5f0595bbe24655141438e7a100b 


ALGORITHM: 
Ed25519 


SECRET KEY: 
4ccd089p28ff96da9db6c346ec114e0f 
5p8a319£35aba624da8cf6ed4fb8a6fb 


PUBLIC KEY: 
3d4017c3e843895a92b70aa74dlb7ebc 
9c982ccf2ec4968cc0cd55f12af4660c 


MESSAGE (length 1 byte): 
72 


SIGNATURE: 

92a009a9f0d4cab8720e820b5f642540 
a2b27b5416503f8fb3762223ebdb69%da 
0O85acle43e15996e458f3613d0f11d8c 
387b2eaeb4302aeeb00d291612bb0c00 
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ALGORITHM: 
Ed25519 


SECRET KEY: 
c5aa8df43f9f£837bedb7442£31dcb7b1 
664d38535076£094585ce3a2e0b4458£7 


PUBLIC KEY: 
fc51cd8e6218a1a38da47ed00230£058 
0816ed13ba3303ac5deb911548908025 


MESSAGE (length 2 bytes): 
af82 


SIGNATURE: 

6291d657deec24024827e69c3abe01a3 
0ce548a284743a445e3680d7db5ac3ac 
18€f9b538d16f290ae67f760984dc659 
4a7c15e9716ed28dc027beceealec40a 


=== TEST 1024 


ALGORITHM: 
Ed25519 


SECRET KEY: 
f5e5767cf153319517630f226876b86c 
8160cc583bc013744c6bf255f5cc0ee5 


PUBLIC KEY: 
278117fc144c72340f67d0f2316e8386 
ceffbf2b2428c9c51fef7c597fld426e 


MESSAGE (length 1023 bytes): 

08b8b2b733424243760fe426a4b54908 
632110a66c2f659leabd3345e3e4eb98 
fa6e264bf09efel2ee50f8f54e9f77b1 
e355f6c50544e23fb1433ddf73be84d8 
79de7c0046dc4996d9e773£4bc9efe57 
3882%adb26c81b37c93a1b270b20329%d 
658675fc6ea534e0810a4432826bf58c 
941efb65d57a338bbd2e26640f89%ffbc 
1a858efcb8550ee3a5e1998bd177e93a 
7363c344fe6b199ee5d02e82d522c4fe 
ba15452f80288a821a579116ec6dad2b 
3b310da903401aa62100ab5d1a36553e 
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06203b33890cc9b832f79ef80560cchb9 
a39ce767967ed628c6ad573cb116dbef 
efd75499da96bd68a8a9750928a8bbc10 
3b6621fcde2becal1231d206be6cd9ec7 
aff6f6c94fcd7204ed3455c68c83f4a4 
1da4af2b74ef5c53f1d8ac70bdcb7ed1 
85ce81bd84359d44254d95629e9855a9 
4a7c1958d1f8ada5d0532ed8a5aa3fb2 
d17ba70eb6248e594e1a2297acbbb39d 
502fla8c6eb6f1ce22b3delalf40cc24 
554119a831a9aad6079cad88425de6bd 
ela9187ebb6092cf67bf2b13fd65f270 
88d78b7e883c8759d2c4f5c65adb7553 
878ad575f9fad878e80a0c9ba63bcbcc 
2732e69485bbc9c90bfbd62481d9089b 
eccf80cfe2df16a2cf65bd92dd597007 
07e0917af48bbb75fed413d238f5555a 
7a569d80c3414a8d0859dc65a46128ba 
b27af87a71314f318c782b23ebfe808b 
82b0ce26401d2e22f04d83d1255dc5la 
ddd3b75a2b1ae0784504df543af8969b 
e3ea7082ff7fc9888c144da2af58429e 
c96031dbcad3dad9af0dcbaaaf268cb8 
fcffead94f3c7ca495e056a9b47acdb7 
51fb73e666c6c655ade8297297d07ad1 
ba5e43f1bca32301651339e22904cc8c 
42£58c30c04aafdb038dda0847dd988d 
cda6f3bfd15c4b4c4525004aa06eeff8 
ca61783aacec57fb3d1f92b0fe2fd1a8 
5f6724517b65e614ad6808d6f6ee34df 
£7310fdc82aebfd904b01e1dc54b2927 
094b2db68d6f903b68401adebf5a7e08 
d78ff4ef5d63653a65040cf9bfd4aca7 
984a74d37145986780fc0b16ac451649 
de6188a7dbdf191f64b5fc5e2ab47b57 
£7£7276cd419c17a3ca8e1b939ae49e4 
88acba6b965610b5480109c8b17b80e1l 
b7b750d£c7598d5d5011fd2dcc5600a3 
2ef5b52alecc820e308aa34272laac09 
43bf6686b64b2579376504ccc493d97e 
6aed3fb0f9cd71a43dd497£01£17c0e2 
cb3797aa2a2£256656168e6c496afc5f 
b93246f6b1116398a346f1a641f3b041 
e989€7914f90cc2c7fff357876e506b5 
0d334ba77c225bc307ba537152f3f161 
Oe4eafe595f6d9d90d11faa933alb5ef1 
369546868a7f3a45a96768d40fd9d034 
12c091c6315cf4fde7cb68606937380d 
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b2eaaa707b4c4185c32eddcdd306705e 
Adclffc872eeee475a64dfac86aba41c 
0618983f8741c5ef68d3al0le8a3b8ca 
c60c905c15fc910840b94c00a0b9d0 


SIGNATURE: 

0aab4c9005015b3e24d7cdf4663326a3a 
87df5e4843b2cbdb67cbf6e460fec350 
aa5371b1508f9f4528ecea23c436d94b 
5e8fcd4f681e30a6ac00a9704a188a03 


POPE TEST SHA(abc) 


ALGORITHM: 
Ed25519 


SECRET KEY: 
833fe62409237b9d62ec77587520911e 
9a759cecld19755b7da901b96dca3d42 


PUBLIC KEY: 
eci72b93ad5e563bf4932c70e1245034 
c35467ef2efd4d64ebf819683467e2bf 


MESSAGE (length 64 bytes): 

ddaf35a193617abacc417349ae204131 
12e6fa4e89a97ea20a9eeee64b55d39a 
2192992a274f£c1a836ba3c23a3feebbd 
454d4423643ce80e2a9ac94fa54ca49f 


SIGNATURE: 

dc2a4459e7369633a52b1bf277839a00 
201009a3efbf3ecb69%bea2186c26b589 
09351fc9ac90b3ecfdfbc7c66431e030 
3dcal79c138ac17ad9bef1177331a704 


ALGORITHM: 
Ed25519ctx 


SECRET KEY: 
0305334e381af78f141cb666f6199f57 
bc3495335a256a95bd2a55bf546663£f6 
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PUBLIC KEY: 
dfc9425e4f968f7f0c29f0259cf5fIae 
d6851c2bb4ad8bfb860cfee0ab248292 


MESSAGE (length 16 bytes): 
£726936d19c800494e3fdaff20b276a8 


CONTEXT: 
666f6f 


SIGNATURE: 

55a4cc2f70a54e04288c5f4cdle45a7b 
b520b36292911876cada7323198dd87a 
8b36950b95130022907a7fb7c4e9b2d5 
f6cca685a587b4b21f4b888e4e7edb0d 


ALGORITHM: 
Ed25519ctx 


SECRET KEY: 
0305334e381af78f141cb666f6199f57 
bc3495335a256a95bd2a55bf546663£f6 


PUBLIC KEY: 
dfc9425e4f968f7f0c29f0259cf5fIae 
d6851c2bb4ad8bfb860cfee0ab248292 


MESSAGE (length 16 bytes): 
£726936d19c800494e3fdaff20b276a8 


CONTEXT: 
626172 


SIGNATURE: 

fc60d5872fc46b3aa69f8b5b4351d580 
8f92bcc044606db097abab6dbcblaee3 
216c48e8b3b66431b5b186d1d28f8eel 
5a5ca2df6668346291c2043d4eb3e90d 


ALGORITHM: 
Ed25519ctx 
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SECRET KEY: 
0305334e381af78f141cb666f6199f57 
bc3495335a256a95bd2a55bf546663£f6 


PUBLIC KEY: 
dfc9425e4f968f7f0c29f0259cf5fIae 
d6851c2bb4ad8bfb860cfee0ab248292 


MESSAGE (length 16 bytes): 
508e9e6882b979fea900f62adceaca35 


CONTEXT: 
666f6f 


SIGNATURE: 

8b70c1cc8310e1de20ac53ce28ae6e72 
07£33c3295e035bb5c0732a1d20dc6490 
8922a8b052cf99b7c4fel07a5abb5b2c 
4085ae75890d02df26269d8945f£84b0b 


ALGORITHM: 
Ed25519ctx 


SECRET KEY: 
ab9c2853ce297ddab85c993b3ael4bca 
d39b2c682beabc27d6d4eb20711d6560 


PUBLIC KEY: 
0f1d1274943b91415889152e893d80e9 
3275alfc0b65fd71b4b0ddal0ad7d772 


MESSAGE (length 16 bytes): 
£726936d19c800494e3fdaff20b276a8 


CONTEXT: 
666f6f 


SIGNATURE: 

21655b5flaa965996b3f97b3c849eafb 
a922a0a62992f73b3d1b73106a84ad85 
e9b86a7b6005ea868337ff2d20a7f5fl 
d4cdi10b0be49a68da2b2e0dc0ad8960f 
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7.3. Test Vectors for Ed25519ph 
is TEST abc 


ALGORITHM: 
Ed25519ph 


SECRET KEY: 
833fe62409237b9d62ec77587520911e 
9a759cecld19755b7da901b96dca3d42 


PUBLIC KEY: 
eci72b93ad5e563bf4932c70e1245034 
c35467ef2efd4d64ebf819683467e2bf 


MESSAGE (length 3 bytes): 
616263 


SIGNATURE: 

98a70222£058121aa9d30£8134d683£80 
9e462b469c7££87639499bb94e6dae41 
31£85042463c2a355a2003d062adf5aa 
al0b8c61e636062aaad11c2a26083406 


7.4. Test Vectors for Ed448 


ALGORITHM: 
Ed448 


SECRET KEY: 
6c82a562cb808d10d632be89c8513ebf 
6c929£f34ddfa8c9f63c9960ef6e348a3 
528c8a3fcc2f044e39a3fc5b94492f8f 
032e7549a20098f95b 


PUBLIC KEY: 
5fd7449b59b461fd2ce787ec6l6ad46a 
1da1342485a70elf8a0ea75d80e96778 
edf124769b46c7061bd6783dfle50f6c 
dlfalabeafe8256180 


MESSAGE (length 0 bytes): 
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SIGNATURE: 
533a37f6bbe457251f023c0d88f976ae 
2dfb504a843e34d2074fd823d41a591f 
2b233f034f628281f2fd7a22ddd47d78 
28c59bd0a21bfd3980ff0d2028d4b18a 
9df63e006c5d1c2d345b925d8dc00b41 
04852db9%ac5c7cdda8530a113a0f4db 
b61149f05a7363268c71d95808ff2e65 
2600 


cA 1 octet 


ALGORITHM: 
Ed448 


SECRET KEY: 
c4eab05d357007c632f3dbb48489924d 
552b08fe0c353a0d4a1f00acda2c463a 
fbea67c5e8d2877c5e3bc397a659949e 
£8021e954e0a12274e 


PUBLIC KEY: 
43ba28f£430cdff456ae531545f7ecd0a 
c834a55d9358c0372bfa0c6c6798c086 
6aea01eb00742802h8438ea4cb82169c 
235160627b4c3a9480 


MESSAGE (length 1 byte): 
03 


SIGNATURE: 
26b8£91727bd62897af15e41eb43c377 
efb9c610d48£2335cb0bd0087810£435 
2541b143c4b981b7e18f62de8ccdf633 
fclbf037ab7cd779805e0dbcc0aaelcb 
ceelafb2e027df36bc04dcecbf154336 
c19f0af7e0a6472905e799f1953d2a0f 
f3348ab21aa4adafd1d234441cf807c0 
3a00 


EE 1 octet (with context) 


ALGORITHM: 
Ed448 
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SECRET KEY: 
c4eab05d357007c632f3dbb48489924d 
552b08fe0c353a0d4a1f00acda2c463a 
fbea67c5e8d2877c5e3bc397a659949e 
£8021e954e0a12274e 


PUBLIC KEY: 
43ba28f£430cdff456ae531545f7ecd0a 
c834a55d9358c0372bfa0c6c6798c086 
6aea01leb00742802b8438ea4cb82169c 
235160627b4c3a9480 


MESSAGE (length 1 byte): 
03 


CONTEXT: 
666f6f 


SIGNATURE: 
d4£8£6131770dd46f40867d6fd5d5055 
de43541f8c5e35abbcd001b32a89f7d2 
151£7647f11d8ca2ae279fb842d60721 
7fce6e042f6815ea000c85741de5c8da 
1144a6alaba7f96de42505d7a7298524 
fda538fccbbb754f578c1cad10d54d0d 
5428407e85dcbc98a49155c13764e66c 
3c00 


m 11 octets 


ALGORITHM: 
Ed448 


SECRET KEY: 
cd23d24£714274e744343237593290f£5 
11f6425f98e64459ff203e8985083ffd 
£60500553abc0e05cd02184bdb89c4cc 
d67e187951267eb328 


PUBLIC KEY: 
dcea9e78f35a1bf349%1831b10b86c90 
aac01cd84b67a0109b55a36e9328b1e3 
65fcel61d71ce7131a543ea4cb5f7e9f 
1d8b00696447001400 


MESSAGE (length 11 bytes): 
0c3e544074ec63b0265e0c 
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SIGNATURE: 
1£0a8888ce25e8d458a21130879b840a 
9089d999aaba039eaf3e3afa090a09d3 
89dba82c4ff2ae8ac5cdfb7c55e94d5d 
961a29fe0109941e00b8dbdeea6d3b05 
1068df7254c0cdc129cbe62db2dc957d 
bb47b51fd3f213fb8698f064774250a5 
028961c9bf8f£fd973fe5d5c206492b14 
0e00 


mi E DLE 12 octets 


ALGORITHM: 
Ed448 


SECRET KEY: 
258cdd4ada32ed9c9ff54e63756ae582 
fb8fab2ac721f2c8e676a72768513d93 
9f63dddb55609133£29adf86ec9929dc 
cb52clc5fd2ff7e21b 


PUBLIC KEY: 
3bal6da0c6f2cclf30187740756f5e79 
8d6bc5fc015d7c63cc9510ee3fd44adc 
24d8e968b6e46e6f94d19b945361726b 
d75e149ef09817£580 


MESSAGE (length 12 bytes): 
64a65f3cdedcdd66811e2915 


SIGNATURE: 
Teeeab7c4e50fb799%b418ee5e3197ff6 
bf15d43a14c34389%b5%ddla7b1b85b4a 
e90438aca634bea45e3a2695f1270f07 
fdcdf7c62b8efeaf00b45c2c96ba457e 
bl1a8bf075a3db28e5c24f6b923ed4ad7 
47c3c9e03c7079%efb87cb110d3a99861 
e72003cbae6d6b8b827e4e6c143064ff 
3c00 


E E 13 octets 


ALGORITHM: 
Ed448 
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SECRET KEY: 
7ef1e84544236752fbb56b8f31a23a10 
e42814f5f55ca037cdcc11c64c9a3b29 
49c1bb60700314611732a6c2fea98eeb 
c0266a11a93970100e 


PUBLIC KEY: 
b3da079b0aa493a5772029£0467baebe 
e5a8112d9d3a22532361da294f7bb381 
5c5dc59e1765b4d9£381ca0938e13c6c0 
7b174be65dfa578e80 


MESSAGE (length 13 bytes): 
64a65f3cdedcdd66811e2915e7 


SIGNATURE: 
6a12066£55331b6c22acd5d5bfc5d712 
28 fbda80ae8dec26bdd306743c5027cb 
4890810c162c027468675ecf645a8317 
6c0d7323a2ccde2d80efe5al268e8aca 
1d6fbc194d3f77c44986eb4ab4177919 
ad8bec33eb47bbb5fc6e28196fdlcaf5 
6b4e7e0ba5519234d047155ac727a105 
3100 


=== 64 octets 


ALGORITHM: 
Ed448 


SECRET KEY: 
d65df341ad13e008567688baedda8e9d 
cdc17dc024974ea5b4227b6530e339bf 
f21f99e68ca6968f3cca6dfeO0fb9f4fa 
b4fal35d5542ea3f01 


PUBLIC KEY: 
df9705f58edbab802c7f8363cfe5560a 
b1c6132c20a9f1dd163483a26f8ac53a 
39d6808bf4aldfbd261b099bb03b3fb5 
0906cb28bd8a081f00 


MESSAGE (length 64 bytes): 

bd0f6a3747cd561bdddf4640a332461a 
4a30a12a434cd0bf40d766d9c6d458e5 
512204a30c17d1£50b5079631f64eb31 
12182da3005835461113718dla5ef944 
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SIGNATURE: 
554bc2480860b49%eab8532d2a533b7d5 
78ef473eeb58c98bb2d0e1ce488a98b1 
8dfde9b9b90775e67f47d4alc3482058 
efc9f40d2ca033a0801b63d45b3b722e 
f552bad3b4ccb667da350192b61c508c 
f7b6b5adadc2c8d9a446ef003fb05cba 
5£30e88e36eCc2703b349ca229C267083 
3900 


=== 256 octets 


ALGORITHM: 
Ed448 


SECRET KEY: 
2ec5fe3c17045abdb136a5e6a913e32a 
b75ae68b53d2fc149%b77e504132d3756 
9b7e766ba74al 9bd6162343a21c8590a 
a9cebca9014c636df5 


PUBLIC KEY: 
79756f014dcfe2079f5dd9e718be4171 
e2ef2486a08f25186f6bff43a9936b9b 
fe12402b08ae65798a3d81e22e9ec80e 
7690862ef3d4ed3a00 


MESSAGE (length 256 bytes): 

15777532b0bdd0d1389f636c5f6b9ba7 
34c90af572877e2d272dd078aale567c 
fa80e12928bb542330e8409f31745041 
07ecd5efac61ae7504dabe2a602ede89 
e5cca6257a77c17e27a702b3ae39£c769 
fc54f2395ae6a1178cab4738e543072f 
clc177fe71e92e25bf03e4ecb72f47b6 
4d0465aaea4c7f£ad372536c8ba516a60 
39c3c2a39f0e4d832be432dfa9%a706a6 
e5c/e19f397964ca4258002f7c0541b5 
90316dbc5622b6b2a6fe7a4abffd9610 
5eca76ea7098816af£0748c10df048ce0 
12d901015a51£189f3888145c03650aa 
23ce894c3bd889e030d565071c59£409 
a99815051878f£d6fc110624dcbcde0bf7 
a69ccce38fabdf86f3bef6044819de11 
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SIGNATURE: 
c650ddbb0601c19ca11439e1640dd931 
f43c518ea5bea70d3dcde5f4191fe53f 
00cf£966546b72bcc7d58be2b9badef28 
743954e3a44a23f880e8d4f1cfce2d7a 
61452d26da05896f0a50da66a239a8al 
88b6d825b3305ad77b73fbac0836ecc6 
0987fd08527c1a8e80d5823e65cafe2a 
3d00 


=== 1023 octets 


ALGORITHM: 
Ed448 


SECRET KEY: 
872d093780£5d3730d£7c212664b37b8 
a0f24f56810daa8382cd4fa3f77634ec 
44dc54f1c2ed%hbea86fafb7632d8be19 
9eal65f5ad55dd9ce8 


PUBLIC KEY: 
a81b2e8a70a5ac94ffdbcc9badfc3feb 
0801f£258578bb114ad44ecelec0e799d 
a08effb81c5d685c0c56f64eecaef8cd 
f11cc38737838cf400 


MESSAGE (length 1023 bytes): 

6ddf802elaae1986935f7f981lba3f035 
1d6273c0a0c22c9c0e8339168e675412 
a3debfaf435ed651558007db4384b650 
fcc07e3b586a27a4f7a00ac8abfec2cd 
86ae4bf1570c41e6a40c931db27b2faa 
15a8cedd52cff7362c4e6e23daecOfbc 
3a79b6806e316efcc7068119bf46bc76 
a26067a53f£296dafdbdcl11c77£7777e9 
72660cf4b6a9b369a6665f02e0cc9b6e 
dfad136b4 fabe723d2813db3136cfde9 
b6d044322fee2947952e031b73ab5c60 
3349b307bdc27bc6cb8b8bbd7bd32321 
98033a581b59%eadebb09%b3c4f3d2277 
d4f0343624acc817804728b25ab79717 
2b4c5c21a22f9c7839d64300232eb66e 
53f31c723fa37fe387c7d3e50bdf9813 
a30e5bb12cf4cd930c40cfb4elfc6225 
92a49588794494d56d24ea4b40c89fc0 
596cc9ebb961c8cb10adde976a5d602b 
1c3f85b9b9a001ed3c6a4d3b1437£520 
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96cd1956d042a597d561a596ecd3d173 
5a8d570ea0ec27225a2c4aaff26306d1 
526claf3ca6d9Icf5a2c98f47elc46db9 
a33234cfd4d81f2c98538a09ebe76998 
d0d8fd25997c7d255c6d66ece6fa56f1 
1144950f027795e653008f4bd7ca2dee 
85d8e90f3dc315130ce2a00375a318c7 
c3d97be2c8êce5b6db41a6254ff264fa6 
155baee3b0773c0f497c573f19bb4f42 
40281f0b1f4f7be857a4e59d416c06b4 
c50fa09e1810ddc6b1467baeac5a3668 
dilb6ecaa901440016f389f80acc4db9 
77025e7£5924388c7e340a732e554440 
e76570£8dd71b7d640b3450d1fd5f041 
0a18f9a3494f707c717b79b4bf75c984 
00b096b21653b5d217c£3565c9597456 
f707034972078763829%bc01bb1cbc8fa 
04eadc9a6e3f6699587a9e75c94e5bab 
0036e0b2e711392cff0047d0d6b05bd2 
a588bc109718954259f1d86678a579a3 
120f19cfb2963f177aeb70f2d4844826 
262e51b80271272068ef5b3856fa8535 
aa2a88b2d41f2a0e2fda7624c2850272 
ac4a2f561f8f2f7a318bfd5caf969614 
9e4ac824ad3460538£dc25421beec2cc 
6818162d06bbed0c40a387192349db67 
ali8bada6cd5ab0140ee273204f628aa 
d1c135f770279a651e24d8c14d75a605 
9d76b96a6fd857def5e0b354b27ab937 
a5815d16b5fae407ff18222c6dled263 
be68c95f32d908bd895cd76207ae7264 
87567f9a67dad79abec316f683b17f2d 
02bf07e0ac8b5bc6162cf94697b3c27c 
dl fea49b27£23ba2901871962506520c 
392da8b6ad0d99f7013fbc06c2c17a56 
9500c8a7696481c1cd33e9%b14e40b82e 
79a5f5db82571ba97bae3ad3e0479515 
bb0e2b0f3bfcd1fd33034efc6245eddd 
7ee2086ddae2600d8ca73e214e8c2b0b 
db2b047c6a464a562ed77b73d2d841c4 
b34973551257713b753632efba348169 
abc90a68f42611a40126d7cb21b58695 
568186f7e569d2ff0f9e745d0487dd2e 
b997cafc5abf9dd102e62ff66cba87 
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SIGNATURE: 
e301345a41a39a4d72fff8df69c98075 
a0cco82b802fc9b2b6bc503£926b65bd 
df7f4c8fl1cb49f6396afc8a70abe6d8a 
ef0db478d4c6b2970076c6a0484fe76d 
7603a97625d79£1ce240e7c576750d29 
5528286f719b413de9ada3e8eb78ed57 
3603ce30d8bb761785dc30dbc320869e 
1a00 


7.5. Test Vectors for Ed448ph 
Se TEST abc 


ALGORITHM: 
Ed448ph 


SECRET KEY: 
833fe62409237b9d62ec77587520911e 
9a759cecld19755b7da901b96dca3d42 
ef7822e0d5104127dc05d6dbefde69e3 
ab2cec7c867c6e2c49 


PUBLIC KEY: 
259b71c19f83ef77a7abd26524cbdb31 
615590a48f7d17de3ee0ba9c52beb743 
c09428a131d6b1b57303d90d8132c276 
d5ed3d5d01c0f53880 


MESSAGE (length 3 bytes): 
616263 


SIGNATURE: 
822f6901£7480f3d5f£562c592994d969 
3602875614483256505600bbc281lae38 
1f54d6bce2ea911574932f52a4e6cadd 
78769375ec3ffdlb801a0d9b3f4030cd 
433964b6457ea39476511214f97469%b5 
7dd32dbc560a9a94d00bff07620464a3 
ad203df7dc7ce360c3cd3696d9d9fab9 
Of00 
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=== TEST abc (with context) 


ALGORITHM: 
Ed448ph 


SECRET KEY: 
833fe62409237b9d62ec77587520911e 
9a759cecld19755b7da901b96dca3d42 
ef7822e0d5104127dc05d6dbefde69e3 
ab2cec7c867c6e2c49 


PUBLIC KEY: 
259b71c19f83ef77a7abd26524cbdb31 
615590a48f7d17de3ee0ba9c52beb743 
c09428a131d6b1b57303d90d8132c276 
d5ed3d5d01c0f53880 


MESSAGE (length 3 bytes): 
616263 


CONTEXT: 
666f6f 


SIGNATURE: 
c32299d46ec8ff02b54540982814dce9 
a05812f81962b649d528095916a2aa48 
1065b1580423ef927ecf0af5888£90da 
0f6a9a85ad5dc3f280d91224ba9911a3 
653d00e484e2ce232521481c8658d£30 
4bb7745a73514cdb%bf3e15784ab7128 
4f8d0704a608c54a6b62d97beb511d13 
2100 
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8. Security Considerations 
8.1. Side-Channel Leaks 


For implementations performing signatures, secrecy of the private key 
is fundamental. It is possible to protect against some side-channel 
attacks by ensuring that the implementation executes exactly the same 
sequence of instructions and performs exactly the same memory 
accesses, for any value of the private key. 


To make an implementation side-channel silent in this way, the modulo 
p arithmetic must not use any data-dependent branches, e.g., related 
to carry propagation. Side-channel silent point addition is 
straightforward, thanks to the unified formulas. 


Scalar multiplication, multiplying a point by an integer, needs some 
additional effort to implement in a side-channel silent manner. One 
simple approach is to implement a side-channel silent conditional 
assignment, and use it together with the binary algorithm to examine 
one bit of the integer at a time. 


Compared to other signature schemes, avoiding data-dependent branches 
is easier due to side-channel silent modulo p arithmetic being easier 
(with recommended curves) and having complete addition formulas 
instead of having a number of special cases. 


Note that the example implementations in this document do not attempt 
to be side-channel silent. 


8.2. Randomness Considerations 


EdDSA signatures are deterministic. This protects against attacks 
arising from signing with bad randomness; the effects of which can, 
depending on the algorithm, range up to full private key compromise. 
It can be surprisingly hard to ensure good-quality random numbers, 
and there have been numerous security failures relating to this. 


Obviously, private key generation requires randomness, but due to the 
fact that the private key is hashed before use, a few missing bits of 
entropy doesn’t constitute a disaster. 


The basic signature verification is also deterministic. However, 


some speedups by verifying multiple signatures at once do require 
random numbers. 
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8.3. Use of Contexts 


Contexts can be used to separate uses of the protocol between 
different protocols (which is very hard to reliably do otherwise) and 
between different uses within the same protocol. However, the 
following SHOULD be kept in mind when using this facility: 


The context SHOULD be a constant string specified by the protocol 
using it. It SHOULD NOT incorporate variable elements from the 


message itself. 


Contexts SHOULD NOT be used opportunistically, as that kind of use 


is very error prone. If contexts are used, one SHOULD require all 
signature schemes available for use in that purpose support 
contexts. 


Contexts are an extra input, which percolate out of APIs; as such, 
even if the signature scheme supports contexts, those may not be 
available for use. This problem is compounded by the fact that 
many times the application is not invoking the signing and 
verification functions directly but via some other protocol. 


8.4. Signature Malleability 


Some systems assume signatures are not malleable: that is, given a 
valid signature for some message under some key, the attacker can’t 
produce another valid signature for the same message and key. 


Ed25519 and Ed448 signatures are not malleable due to the 
verification check that decoded S is smaller than 1. Without this 
check, one can add a multiple of 1 into a scalar part and still pass 
signature verification, resulting in malleable signatures. 


8.5. Choice of Signature Primitive 


Ed25519 and Ed25519ph have a nominal strength of 128 bits, whereas 
Ed448 and Ed448ph have the strength of 224. While the lower strength 
is sufficient for the foreseeable future, the higher level brings 
some defense against possible future cryptographic advances. Both 
are demolished by quantum computers just about the same. 


The Ed25519ph and Ed448ph variants are prehashed. This is mainly 
useful for interoperation with legacy APIs, since in most of the 
cases, either the amount of data signed is not large or the protocol 
is in the position to do digesting in ways better than just 
prehashing (e.g., tree hashing or splitting the data). The 
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prehashing also makes the functions greatly more vulnerable to 
weaknesses in hash functions used. These variants SHOULD NOT be 
used. 


Ed25519ctx and Ed448 have contexts. However, this is balanced by the 
problems noted in Section 8.3 about contexts. 


On the implementation front, Ed25519 is widely implemented and has 
many high-quality implementations. The others have much worse 
support. 


In summary, if a high 128-bit security level is enough, use of 
Ed25519 is RECOMMENDED; otherwise, Ed448 is RECOMMENDED. 


8.6. Mixing Different Prehashes 


The schemes described in this document are designed to be resistant 
to mixing prehashes. That is, it is infeasible to find a message 
that verifies using the same signature under another scheme, even if 
the original signed message was chosen. Thus, one can use the same 
key pair for Ed25519, Ed25519ctx, and Ed25519ph and correspondingly 
with Ed448 and Ed448ph. 


The "SigEd25519 no Ed25519 collisions" constant is chosen to be a 
textual string such that it does not decode as a point. Because the 
inner hash input in the Ed25519 signature always starts with a valid 
point, there is no way trivial collision can be constructed. In the 
case of seed hash, trivial collisions are so unlikely, even with an 
attacker choosing all inputs, that it is much more probable that 
something else goes catastrophically wrong. 


8.7. Signing Large Amounts of Data at Once 


Avoid signing large amounts of data at once (where "large" depends on 
the expected verifier). In particular, unless the underlying 
protocol does not require it, the receiver MUST buffer the entire 
message (or enough information to reconstruct it, e.g., compressed or 
encrypted version) to be verified. 


This is needed because most of the time, it is unsafe to process 
unverified data, and verifying the signature makes a pass through the 
whole message, causing ultimately at least two passes through. 


As an API consideration, this means that any Initialize Update 
Finalize (IFU) verification interface is prone to misuse. 
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It is a bad idea to modify Ed25519 or Ed448 signing to be able to 
create valid Ed25519/Ed448 signatures using an IUF interface with 
only constant buffering. Pretty much any error in such would cause 
catastrophic security failure. 


8.8. Multiplication by Cofactor in Verification 


The given verification formulas for both Ed25519 and Ed448 multiply 
points by the cofactor. While this is not strictly necessary for 
security (in fact, any signature that meets the non-multiplied 
equation will satisfy the multiplied one), in some applications it is 
undesirable for implementations to disagree about the exact set of 
valid signatures. Such disagreements could open up, e.g., 
fingerprinting attacks. 


8.9. Use of SHAKE256 as a Hash Function 


Ed448 uses SHAKE256 as a hash function, even if SHAKE256 is 
specifically defined not to be a hash function. 


The first potentially troublesome property is that shorter outputs 
are prefixes of longer ones. This is acceptable because output 
lengths are fixed. 


The second potentially troublesome property is failing to meet 
standard hash security notions (especially with preimages). However, 
the estimated 256-bit security level against collisions and preimages 
is sufficient to pair with a 224-bit level elliptic curve. 
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Appendix A.  Ed25519/Ed448 Python Library 


Below is an example implementation of Ed25519/Ed448 written in 
Python; version 3.2 or higher is required. 


Note: This code is not intended for production. Although it should 
produce correct results for every input, it is slow and makes no 
attempt to avoid side-channel attacks. 


import hashlib; 
import os; 


#Compute candidate square root of x modulo p, with p = 3 (mod 4). 
def sqrt4k3(x,p): return pow(x, (p + 1)//4,p) 
#Compute candidate square root of x modulo p, with p = 5 (mod 8). 


def sqrt8k5(x,p): 
y = pow(x, (p+3)//8,p) 
fIf the square root exists, it is either y or y*2” (p-1)/4. 
if (y * y) 3 p == $ p: return y 
else: 
z = pow(2,(p - 1)//4,p) 
return (y * z) $ p 
#Decode a hexadecimal string representation of the integer. 
def hexi(s): return int.from bytes (bytes.fromhex (s) byteorder="big") 


#Rotate a word x by b places to the left. 
def rol(x,b): return ((x «« b) | (x »» (64 - b))) & (2**64-1) 


#From little endian. 
def from_le(s): return int.from_bytes(s, byteorder="little") 


#Do the SHA-3 state transform on state s. 
def sha3_transform(s): 

ROTATIONS = [0,1,62,28,27,36,44,6,55,20, 3,10, 43,25, 39, 41,45,15,\ 

21,8,18,2,61,56,14] 

PERMUTATION = [1,6,9,22,14,20,2,12,13,19,23,15,4,24,21,8,16,5, 3, \ 

18/17, LL, 7 LO] 

RC = [0x0000000000000001, 0x0000000000008082, 0x800000000000808a, \ 
0x8000000080008000, 0x000000000000808b, 0x0000000080000001, \ 
0x8000000080008081, 0x8000000000008009, 0x000000000000008a, \ 
0x0000000000000088, 0x0000000080008009, 0x000000008000000a, \ 
0x000000008000808b, 0x800000000000008b, 0x8000000000008089, \ 
0x8000000000008003, 0x8000000000008002, 0x8000000000000080, \ 
0x000000000000800a, 0x800000008000000a, 0x8000000080008081, \ 
0x8000000000008080,0x0000000080000001,0x8000000080008008] 
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for rnd in range(0,24): 

#AddColumnParity (Theta) 

c = [0]*5; 

d [0]*5; 

for i in range(0,25): c[i%5]*=s[i] 

for i in range(0,5): d[il=c[ (it+4)%5]*rol(c[(it+1)%5],1) 

for i in range(0,25): s[i]*=d[i%5] 

#RotateWords (Rho) 

for i in range(0,25): s[il-rol(s[i],ROTATIONS[i]) 

#PermuteWords (Pi) 

t = s[PERMUTATION[0]] 

for i in range(0,len(PERMUTATION)-1): 
s[PERMUTATION[i]]=s[PERMUTATION[i+1]] 

S[PERMUTATION[-1]]^t; 

#NonlinearMixRows (Chi) 

for i in range(0,25,5): 
t=[s[i],s[itl],s[it2],s[it+3],s[it4],s[i],s[it1]] 
for j in range(0,5): s[i+31=t[31* (("t[3+1]1)€ (t[3+2])) 

#AddRoundConstant (Iota) 

s[0]*=RC [rnd] 


#Reinterpret octet array b to word array and XOR it to state s. 
def reinterpret_to_words_and_xor(s,b): 
for j in range(0,1en(b)//8): 
s[j]*=from_le(b[8* j:][:8]) 


#Reinterpret word array w to octet array and return it. 
def reinterpret to octets(w): 
mp=bytearray () 
for j in range(0,len(w)): 
mp+=w[3].to_bytes (8, byteorder="little") 
return mp 
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f (semi-)generic SHA-3 implementation 
def sha3 raw(msg,r w,o p,e b): 

r b-8*r w 

s=[0]*25 

#Handle whole blocks. 

idx=0 

blocks=len (msg) //r_b 

for i in range(0,blocks): 
reinterpret to words and xor(s,msg[idx:][:r b]) 
idx+=r_b 
sha3_transform(s) 

#Handle last block padding. 

m=bytearray (msg[idx:]) 

m.append (o. p) 

while len(m) « r b: m.append(0) 

m[len (m) -1] |=128 

#Handle padded last block. 

reinterpret_to_words_and_xor (s,m) 

sha3_transform(s) 

#Output. 

out = bytearray () 

while len(out)<e_b: 
out+=reinterpret_to_octets(s[:r_w]) 
sha3_transform(s) 

return out[:e_b] 


#Implementation of SHAKE256 functions. 
def shake256(msg,olen): return sha3 raw(msg,17,31,olen) 
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#A (prime) field element. 
class Field: 
#Construct number x (mod p). 
def | init  (self,x,p): 
self.  x-x$p 
self. p=p 
#Check that fields of self and y are the same. 
def | check fields(self,y): 
if type(y) is not Field or self. pl=y. p: 
raise ValueError("Fields don't match") 
#Field addition. The fields must match. 
def | add  (self,y): 
self. check fields(y) 
return Field(self. x*y. x,self. p) 
#Field subtraction. The fields must match. 
def sub  (self,y): 
self. check fields(y) 
return Field(self.__ptself.__x-y.__x, self.__p) 
#Field negation. 
def neg (self): 
return Field(self. p-self._ x,self. p) 
#Field multiplication. The fields must match. 
def mul  (self,y): 
self. check fields(y) 
return Field(self. x*y. x,self. p) 
#Field division. The fields must match. 
def | truediv  (self,y): 
return self*y.inv() 
#Field inverse (inverse of 0 is 0). 
def inv(self): 
return Field(pow(self. x,self. p-2,self._ p),self._ p) 
#Field square root. Returns none if square root does not exist. 
#Note: not presently implemented for p mod 8 = 1 case. 
def sqrt (self): 
#Compute candidate square root. 
if self.  p$4--3: y=sgrt4k3 (self. x, self. p) 
elif self. p$8==5: y=sgrt8k5 (self. x,self. p) 
else: raise Not ImplementedError ("sqrt (_,8k+1)") 
_y=Field(y,self.__p); 
#Check square root candidate valid. 
return _y if _y*_y==self else None 
#Make the field element with the same field as this, but 
#with a different value. 
def make (self, ival): return Field(ival, self. p) 
#Is the field element the additive identity? 
def iszero (self): return self.  x-- 
#Are field elements equal? 
def eq (self,y): return self. x==y. x and self. p==y. p 
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fAre field elements not equal? 
def _ ne (self,y): return not (self==y) 
#Serialize number to b-1 bits. 
def tobytes (self,b): 
return self.__x.to_bytes(b//8,byteorder="little") 
#Unserialize number from bits. 
def frombytes (self,x,b): 
rv-from le(x)$(2**(b-1)) 
return Field(rv,self. vp) if rv«self. p else None 


#Compute sign of number, 0 or 1. The sign function 
#has the following property: 

#sign(x) = 1 - sign(-x) if x != 0. 

def sign(self): return self.  x$2 


#A point on (twisted) Edwards curve. 
class EdwardsPoint: 

fbase field = None 

#x = None 

#y = None 

fz = None 

def initpoint (self, x, y): 
self.x=x 
self.y=y 
self.z-self.base field.make(1) 

def decode base(self,s,b): 
#Check that point encoding is the correct length. 
if len(s)!-b//8: return (None,None) 
#Extract signbit. 
xs-s[(b-1)//8]»»((b-1) &7) 
#Decode y. If this fails, fail. 
y = self.base field.frombytes (s,b) 
if y is None: return (None,None) 
#Try to recover x. If it does not exist, or if zero and xs 
#are wrong, fail. 
x-self.solve x2(y).sqrt() 
if x is None or (x.iszero() and xs!-x.sign()): 

return (None,None) 

#If sign of x isn't correct, flip it. 
if x.sign()!=xs: x--x 
# Return the constructed point. 
return (x,y) 

def encode base(self,b): 
xp, yp=self.x/self.z,self.y/self.z 
#Encode y. 
s=bytearray (yp.tobytes (b) ) 
#Add sign bit of x to encoding. 
if xp.sign()!=0: s[(b-1)//8] |=1<<(b-1) 38 
return s 
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def mul  (self,x): 
r-self.zero elem() 
s=self 


while x > 0: 
if (x%2)>0: 
r=r+s 
s=s.double () 
x=x//2 
return r 
#Check that two points are equal. 
def _eq__(self,y): 
#Need to check x1/zl == x2/z2 and similarly for y, so cross 
#multiply to eliminate divisions. 
xnl=self.x*y.z 
xn2=y.x*self.z 
ynl-self.y*y.z 
yn2-y.y*self.z 
return xni==xn2 and ynl==yn2 
#Check if two points are not equal. 
def ne (self,y): return not (self--y) 


#A point on Edwards25519. 
class Edwards25519Point (EdwardsPoint): 
#Create a new point on the curve. 
base field-Field(1,2**255-19) 
d--base field.make(121665)/base field.make(121666) 
f0=base field.make(0) 
fl-base field.make(1) 
xb-base field.make (hexi ("21693 6D3CD6E53FECOA4E231FDD6DC5C692CC76"+\ 
"09525A7B2C9562D608F25D51A") ) 
yb=base_field.make (hexi ("666666666666666666666666666666666666666"+\ 
"6666666666666666666666658") ) 
#The standard base point. 
@staticmethod 
def stdbase(): 
return Edwards25519Point (Edwards25519Point.xb, \ 
Edwards25519Point.yb) 
def | init  (self,x,y): 
#Check the point is actually on the curve. 
if y*y-x*x!=self.fl+self.d*x*x*y*y: 
raise ValueError("Invalid point") 
self.initpoint(x, y) 
self.t-x*y 
#Decode a point representation. 
def decode(self,s): 
x, y=self.decode_base(s,256); 
return Edwards25519Point(x, y) if x is not None else None 
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#Encode a point representation. 
def encode (self): 
return self.encode_base(256) 
#Construct a neutral point on this curve. 
def zero_elem(self): 
return Edwards25519Point (self.f0,self.fl) 
#Solve for x^2. 
def solve x2(self,y): 
return ((y*y-self.f1)/(self.d*y*y+self.f1)) 
#Point addition. 
def | add  (self,y): 
#The formulas are from EFD. 
tmp-self.zero elem() 
zcp-self.z*y.z 
A-(self.y-self.x)*(y.y-y.x) 


F,G=D-C,D+C 
tmp.x,tmp.y,tmp.z,tmp.t-E*F,G*H,F*G,E*H 
return tmp 

#Point doubling. 

def double (self): 
fThe formulas are from EFD (with assumption a=-1 propagated). 
tmp=self.zero elem() 
A=self.x*self.x 
B=self.y*self.y 
Ch=self.z*self.z 
C=Ch+Ch 
H=A+B 
xys=self.x+self.y 
E=H-xys*xys 
G=A-B 
F=C+G 
tmp.x,tmp.y,tmp.z,tmp.t-E*F,G*H,F*G,E*H 
return tmp 

#Order of basepoint. 


def l(self): 
return hexi("1000000000000000000000000000000014def9dea2f79cd"-*N 
"65812631a5cf5d3ed") 


#The logarithm of cofactor. 
def c(self): return 3 

#The highest set bit 

def n(self): return 254 
#The coding length 

def b(self): return 256 
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#Validity check (for debugging) 

def is valid point (self): 
X,y,Zz,t-7self.x,self.y,self.z,self.t 
x2=x*x 
y2=y*y 
z2-z*z 
lhs-(y2-x2)*z2 
rhs=z2*z2+self.d*x2*y2 
assert (lhs == rhs) 
assert (t*z == x*y) 


FA point on Edwards448. 

class Edwards448Point (EdwardsPoint): 
#Create a new point on the curve. 
base field-Field(1,2**448-2**224-1) 
d-base field.make(-39081) 
f0=base field.make(0) 
fl-base field.make(1) 
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xb-base field.make (hexi ("4F1970C66BEDODED221D15A622BF36DA9E14657"+\ 
"0470F1767EA6DE324A3D3A46412AE1AF72AB66511433B80E18B00938E26"+X 


"26A82BC70CCO5E") ) 


yb=base_field.make (hexi ("693F46716EB6BC248876203756C9C7624BEA737"+\ 
"36CA3984087789C1E05A0C2D7 3AD3FF1CE67C3 9C4FDBD1 32C4ED7C8AD98"+\ 


"08795BF230FA14") ) 
#The standard base point. 
@staticmethod 
def stdbase(): 


return Edwards448Point (Edwards448Point.xb, Edwards448Point.yb) 


def | init  (self,x,y): 
#Check that the point is actually on the curve. 
if y*y+x*x!=self.fl+self.d*x*x*y*y: 
raise ValueError("Invalid point") 
self.initpoint(x, y) 
#Decode a point representation. 
def decode(self,s): 
x, y=self.decode_base(s,456); 


return Edwards448Point (x, y) if x is not None else None 


#Encode a point representation. 
def encode (self): 
return self.encode_base (456) 
#Construct a neutral point on this curve. 
def zero_elem(self): 
return Edwards448Point (self.f0,self.fl) 
#Solve for x^2. 
def solve x2(self,y): 
return ((y*y-self.f1)/(self.d*y*y-self.f1)) 
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#Point addition. 
def | add  (self,y): 
#The formulas are from EFD. 
tmp-self.zero elem() 
xcp,ycp,zcp-self.x*y.x,self.y*y.y,self.z*y.z 
B=zcp*zcp 
E=self.d*xcp*ycp 
F, G=B-E, B+E 
tmp.x=zcp*F* ((self.xtself.y) *(y.xty.y) -xcp-ycp) 
tmp.y,tmp.z=zcp*G* (ycp-xcp) , F*G 
return tmp 
#Point doubling. 
def double(self): 
#The formulas are from EFD. 
tmp=self.zero elem() 
xls,yls,zls-self.x*self.x,self.y*self.y,self.z*self.z 
xys=self.x+self.y 
F=x1s+yls 
J=F- (zls+zls) 
tmp.x,tmp.y,tmp.z-(xys*xys-xls-yls)*J,F*(xls-yls),F*J 
return tmp 
#Order of basepoint. 
def l(self): 
return hexi ("S3ffffffffffffffffffffffffffffffffffffffffffffff"MN 
"fffffffff7cca23e9c44edb49aed63690216cc27284dc58£552378c2" *N 
"92ab5844f3") 
#The logarithm of cofactor. 
def c(self): return 2 
#The highest set bit. 
def n(self): return 447 
#The coding length. 
def b(self): return 456 
#Validity check (for debugging). 
def is_valid_point (self): 
x,y, z=self.x,self.y,self.z 
x2=x*x 
y2=y*y 
z2-z*z 
lhs=(x2+y2) *z2 
rhs=z2*z2+self.d*x2*y2 
assert (lhs == rhs) 
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Simple self-check. 
def curve self check (point): 
p=point 
a=point.zero_elem() 
z=q 
1=p.1()+1 
p.is valid point () 
q.is valid point () 
for i in range(0,point.b()): 


if (1>>i)81 != 0: 
q=q+p 
q.is valid point () 
p=p.double () 
p.is valid point () 
assert q.encode() == point .encode () 
assert q.encode() != p.encode () 
assert q.encode() != z.encode() 


#Simple self-check. 

def self check curves(): 
curve self check (Edwards25519Point.stdbase()) 
curve self check (Edwards448Point.stdbase()) 


fPureEdDSA scheme. 
#Limitation: only b mod 8 = 0 is handled. 
class PureEdDSA: 
#Create a new object. 
def | init  (self,properties): 
self.B-properties["B"] 
self.H-properties["H"] 
self.l=self.B.1() 
self.n=self.B.n() 
self.b=self.B.b() 
self.c=self.B.c() 
#Clamp a private scalar. 
def _ clamp (self,a): 
_a = bytearray (a) 


for i in range(0,self.c): _a[i//8]&=~ (1<<(i%8) ) 
_alself.n//8] |=1<<(self.n%8) 
for i in range(self.n+1,self.b): _a[i//8]&=" (1<<(i%8) ) 
return _a 

#Generate a key. If privkey is None, a random one is generated. 


#In any case, the (privkey, pubkey) pair is returned. 
def keygen (self, privkey): 
#If no private key data is given, generate random. 
if privkey is None: privkey=os.urandom(self.b//8) 
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#Expand key. 
khash=self.H (privkey, None, None) 
a=from le(self.  clamp(khash[:self.b//8])) 
#Return the key pair (public key is A=Enc(aB). 
return privkey, (self.B*a) .encode () 

Sign with key pair. 

def sign(self,privkey,pubkey,msg,ctx,hflag): 
#Expand key. 
khash=self.H (privkey, None, None) 
a=from le(self.  clamp(khash[:self.b//8])) 
seed=khash[self.b//8:] 
#Calculate r and R (R only used in encoded form). 
r=from le(self.H(seed+msg, ctx, hflag))%self.l 
R=(self.B*r) .encode () 
#Calculate h. 
h=from_le(self.H(Rtpubkeytmsg,ctx,hflag))sself.1 
#Calculate s. 
S=((r+hta)%self.1).to bytes (self.b//8,byteorder="little") 
#The final signature is a concatenation of R and S. 
return R+S 

#Verify signature with public key. 

def verify (self, pubkey, msg, sig, ctx,hflag): 
fSanity-check sizes. 
if len(sig)!=self.b//4: return False 
if len(pubkey) !=self.b//8: return False 
#Split signature into R and S, and parse. 
Rraw, Sraw=sig[:self.b//8],sig[self.b//8:] 
R, S=self.B.decode (Rraw), from le(Sraw) 
#Parse public key. 
A=self.B.decode (pubkey) 
#Check parse results. 
if (R is None) or (A is None) or S»-self.l: return False 
#Calculate h. 
h=from_le(self.H(Rrawt+tpubkey+msg, ctx,hflag))sself.1l 
#Calculate left and right sides of check eq. 
rhs=R+ (A*h) 
lhs=self.B*S 
for i in range(0, self.c): 

lhs = lhs.double() 
rhs = rhs.double() 

#Check eq. holds? 
return lhs==rhs 


def Ed25519 inthash (data, ctx,hflag): 
if (ctx is not None and len(ctx) > 0) or hflag: 
raise ValueError ("Contexts/hashes not supported") 
return hashlib.sha512 (data) .digest () 
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#The base PureEdDSA schemes. 

pEd25519=PureEdDSA ({ \ 
"B":Edwards25519Point.stdbase(),N 
"H":Ed25519 inthashN 

}) 


def Ed25519ctx inthash (data, ctx,hflag): 
dompfx = b"" 
PREFIX=b"SigEd25519 no Ed25519 collisions" 
if ctx is not None: 
if len(ctx) > 255: raise ValueError ("Context too big") 
dompfx-PREFIX-*bytes([1 if hflag else O, len(ctx)])+ctx 
return hashlib.sha512 (dompfx+data) .digest () 


pEd25519ctx=PureEdDSA ((N 
"B":Edwards25519Point.stdbase(),N 
"H":Ed25519ctx inthashWN 

}) 


def Ed448 inthash (data, ctx,hflag): 
dompfx = b"" 
if ctx is not None: 
if len(ctx) > 255: raise ValueError ("Context too big") 
dompfx=b"SigEd448"+bytes([1 if hflag else 0O,len(ctx)])+ctx 
return shake256 (dompfx+data, 114) 


pEd448 = PureEdDSA({\ 
"B":Edwards448Point.stdbase(),\ 
"H":Ed448 inthashWN 


}) 


#EGDSA scheme. 
class EdDSA: 
#Create a new scheme object, with the specified PureEdDSA base 
#scheme and specified prehash. 
def __init__(self,pure_scheme, prehash) : 
self. pflag = True 
self.  pure-pure scheme 
self.  prehash-prehash 
if self.  prehash is None: 
self.  prehash - lambda x,y:x 
self. pflag = False 
# Generate a key. If privkey is none, it generates a random 
# privkey key, otherwise it uses a specified private key. 
# Returns pair (privkey, pubkey). 
def keygen(self,privkey): return self. pure.keygen (privkey) 
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# Sign message msg using specified key pair. 
def sign(self,privkey,pubkey,msg,ctx-None): 
if ctx is None: ctx=b""; 
return self.__pure.sign(privkey, pubkey, self.__ prehash (msg, ctx), \ 
ctx, self.__ pflag) 
# Verify signature sig on message msg using public key pubkey. 
def verify (self, pubkey,msg,sig,ctx=None): 
if ctx is None: ctx=b""; 
return self. pure.verify(pubkey, self. prehash (msg, ctx),sig, \ 
ctx,self.  pflag) 


def Ed448ph prehash (data, ctx): 
return shake256 (data, 64) 


#Our Signature schemes. 

Ed25519 = EdDSA (pEd25519, None) 

Ed25519ctx = ECDSA (pEd25519ctx, None) 

Ed25519ph = EdDSA (pEd25519ctx, lambda x, y:hashlib.sha512 (x) .digest () ) 
Ed448 = EdDSA (pEd448, None) 

Ed448ph = ECDSA (pEd448, Ed448ph prehash) 


def eddsa_obj (name) : 


if name == "Ed25519": return Ed25519 

if name == "Ed25519ctx": return Ed25519ctx 
if name == "Ed25519ph": return Ed25519ph 
if name == "Ed448": return Ed448 

if name == "Ed448ph": return Ed448ph 


raise Not ImplementedError ("Algorithm not implemented") 
Appendix B. Library Driver 


Below is a command-line tool that uses the library above to perform 
computations for interactive use or for self-checking. 


import sys 
import binascii 


from eddsa2 import Ed25519 
def munge string(s, pos, change): 
return (s[:pos] + 


int.to bytes(s[pos] ^ change, 1, "little") + 
s[pos+1:]) 
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# Read a file in the format of 
f http://ed25519.cr.yp.to/python/sign.input 


lineno = 0 
while True: 
line = sys.stdin.readline() 
if not line: 
break 
lineno = lineno + 1 


print (lineno) 

fields = line.split(":") 

secret = (binascii.unhexlify (fields[0])) [:32] 
public = binascii.unhexlify(fields[1]) 

msg = binascii.unhexlify(fields[2]) 

signature = binascii.unhexlify(fields[3])[:64] 


privkey, pubkey = Ed25519.keygen (secret) 
assert public == pubkey 
assert signature == Ed25519.sign(privkey, pubkey, msg) 
assert Ed25519.verify (public, msg, signature) 
if len(msg) == 0: 

bad_msg = b"x" 
else: 

bad_msg = munge_string(msg, len(msg) // 3, 4) 
assert not Ed25519.verify (public, bad_msg, signature) 
assert not Ed25519.verify ( 
assert not Ed25519.verify ( 
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public, msg, munge_string(signature, 20,8) ) 
public,msg,munge string (signature, 40,16) ) 
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